…R for mahua-qcb

Wire up the required LDO supplies on the QCB board.

Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>

… voltage for SD-card

SD cards may need 1.8v VDDIO also to be supported, to accommodate this
requirement reduce the min voltage to 1.8v for `vreg_l2b_e0` which
supplies to VDDIO pin of SD card.

NOTE - Since this SD card is the only client on this regulator, this
change should not have any side effect on any other clients.
moreover, SD card driver takes care to explicitly vote for the
regulator voltage based on the SD card detection sequence.

Also for stable operation of the SD card increase VDD voltage
supplied by `vreg_l9b_e0` to 2.96v.

Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260702094056.3755467-2-mchunara@oss.qualcomm.com/
Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com>

Document the Glymur-specific SDHCI compatible in the sdhci-msm binding.
Use "qcom,sdhci-msm-v5" as the fallback compatible for the MSM SDHCI v5
controller used on Glymur.

Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260703-loutish-stimulating-hummingbird-aada5e@quoll/
Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com>

Add support for SD card on Glymur SoC and enable the required pinctrl
configurations.

Co-developed-by: Sachin Rathore <sachin.rathore@oss.qualcomm.com>
Signed-off-by: Sachin Rathore <sachin.rathore@oss.qualcomm.com>
Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260702094056.3755467-4-mchunara@oss.qualcomm.com/
Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com>

Enable SD card for Glymur CRD platform. Configure the vmmc/vqmmc
regulators and gpio-based card detection for the platform.

Co-developed-by: Sachin Rathore <sachin.rathore@oss.qualcomm.com>
Signed-off-by: Sachin Rathore <sachin.rathore@oss.qualcomm.com>
Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260702094056.3755467-5-mchunara@oss.qualcomm.com/
Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com>

The traceNoC node is the system-level Aggregator TNOC, so it must own a
valid ATID that tags the whole aggregation path. It was marked compatible
with "qcom,coresight-itnoc", an Interconnect TNOC, which is never assigned
an ATID. As a result the aggregator had no trace ID and could not tag the
merged trace.

An Interconnect TNOC is a subsystem-level aggregator: it merges trace from
the ATB sources within its subsystem (TPDMs and other ATB masters) and
forwards the combined stream to the system-level Aggregator TNOC. It
carries no ATID of its own, because the Aggregator TNOC downstream in the
path already owns the ATID.

Switch the node to "qcom,coresight-tnoc" so it is described as the
Aggregator TNOC it is and is assigned a system trace ID. Rename the node
to "tn" and use the "apb_pclk" clock name as required by the Aggregator
TNOC binding.

Link: https://lore.kernel.org/all/20260710-fix-tracenoc-probe-issue-v6-5-41eb36fef8d9@oss.qualcomm.com/
Fixes: 1f7d0c4 ("arm64: dts: qcom: glymur: add coresight nodes")
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>

Embedded Trace Router(ETR) is working as a DDR memory sink to collect
tracing data from source device and the CTCU device serves as the
control unit for the ETR device.

Link: https://lore.kernel.org/all/20260714-add-ctcu-etr-for-glymur-v1-1-791de63c0713@oss.qualcomm.com/
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>

…ature Sensor

Document the Temperature Sensor (TSENS) on the Qualcomm Maili SoC.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Haritha S K <haritha.k@oss.qualcomm.com>
Link: https://patch.msgid.link/20260619-b4-maili-upstream-3-v2-1-e54516c37022@oss.qualcomm.com

The OS PDC DRV register window on eliza spans 0x10000 bytes. Reduce
the size of the first reg entry from 0x40000 to 0x10000.

Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://patch.msgid.link/20260527094333.2311731-25-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>

…board

Document the compatible strings for the Qualcomm Eliza CQS
System-on-Module (SoM) and its EVK board.

The SoM is populated with a CQ7790S Eliza variant, PMICs, LPDDR and
eMMC. The SoM is then connected to the EVK base board, which provides
a multitude of connectors for peripherals.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>

The Eliza CQS (CQ7790S) System-on-Module is designed to be connected to
an Eliza EVK base board. The SoM provides the SoC, PMICs, LPDDR and eMMC,
while the EVK base board provides connectors for a multitude of
peripherals.

Add the Eliza CQS SoM DTSI so it can be included by the EVK board DTS.
Describe the regulators and board clocks, enable eMMC support through
SDHC1, specify the ADSP firmware and enable the ADSP remoteproc.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>

The Eliza CQS EVK board combines the CQ7790S-based (Eliza) SoM with the
common Eliza EVK base board, which provides connectors for different
peripherals.

Add a common Eliza EVK dtsi for the base board bits that can be reused
alongside other Eliza SoM variants. Then, add the final Eliza CQS EVK dts,
including the CQS SoM and common EVK dtsi.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>

Both the CQS SoM and the MTP have the following array of PMICs:
PMK8550, PM7550, 2x PM8550VS, PMIV0102 and PMR735D.

Since on Eliza there is already support for SPMI multi-master,
it is necessary to duplicate the devicetree description for each
of these PMICs, due to the SPMI bus index and address.

So add a new Elize specific dtsi for each of these PMICs and include
all of them in both the CQS SoM and MTP board dts.

Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>

Add the device nodes for the multimedia clock controllers (cambistmclkcc,
camcc, videocc, gpucc) for Qualcomm Eliza SoC.

Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://patch.msgid.link/20260525-eliza_mm_cc_v2-v5-7-a1d125619a5a@oss.qualcomm.com
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>

Eliza supports two PCIe instances: one 8GT/s x1 (PCIe0) and one 8GT/s x2
(PCIe1). Add PCIe controller and PHY nodes for both instances, and update
the GCC clock references to use the newly added PHY nodes instead of
placeholder zeros.

Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>

Even though the EVK comes with 3 Type-C ports, the Eliza EVK only has
one USB controller and a single set of PHYs, which are connected to
the port marked as JUSB.

Also, the EVK comes with an SD card slot.

So describe the PMIC GLINK node, the connector graph, the PHYs and repeater
supplies and enable the USB controller.

Also enable the second SD host controller, describe the card detect GPIO
and the board specific supplies.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>

Describe the ADSP Generic Packet Router (GPR) devicetree node as
part of audio subsystem on Qualcomm Eliza SoC.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>

Add the nodes to describe the GPU SMMU.

Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>

Adreno 722 found in Eliza chipset belongs to the A7x GEN1 family. It is
derived from A730 and shares the same IP-level configurations: HWCG
registers, protected registers, GBIF CX registers and gmu_cgc_mode.
Major differences include lower cache/core counts, 1MB GMEM, no
Concurrent Binning & LPAC support. Some of the peripheral blocks like
RSCC are from A740 that resulted in updates to RSC layout.

Add the necessary devicetree nodes to describe this GPU.

Signed-off-by: Puranam V G Tejaswi <puranam.tejaswi@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>

Enable the Adreno A722 GPU on the Eliza MTP board and provide the zap
shader firmware path.

Signed-off-by: Puranam V G Tejaswi <puranam.tejaswi@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>

Add SoC-level LPASS WSA macro, VA macro, SoundWire controller and LPASS
LPI pin controller nodes. DMIC and WSA SoundWire pinctrl states are
defined inside the LPASS LPI pin controller node. The hardware is similar
to the SM8750 platform.

The WSA macro, VA macro and SoundWire controller are kept disabled so
board DTS files can selectively enable and configure them.

Signed-off-by: Ravi Hothi <ravi.hothi@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>

…with WSA8845 and DMIC

Enable the sound card on the Eliza CQS EVK platform, including the
WSA8845 external speaker path and DMIC microphone capture via VA macro.

Enable the required LPASS WSA macro, VA macro and SoundWire controller
along with the necessary pinctrl configurations for DMIC and WSA
SoundWire interfaces.

Signed-off-by: Ravi Hothi <ravi.hothi@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>

Describe the CPU and LLCC bandwidth monitor nodes for Eliza, together
with the corresponding OPP tables.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>

The Eliza MTP uses a Goodix GT9916 touchscreen controller connected
over SPI.

Describe the controller, its power supply, interrupt and reset GPIOs to
enable touchscreen support.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>

Since each serial engine will be enabled as needed in each board dts,
there is no point of disabling the first QUPv3 wrapper in SoC dtsi.

So enable it by default. This is also now in line with the other SoCs, and
also with the second QUPv3 wrapper.

Fixes: 844807e ("arm64: dts: qcom: eliza: Add QUPv3, GPI DMA, SDHCI and LLCC nodes")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://patch.msgid.link/20260709-dts-qcom-eliza-enable-qupv3-1st-v1-1-e9a6904d0dea@oss.qualcomm.com
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>

A wrong channel survey index was introduced in
ath12k_mac_op_get_survey by [1], which can cause ACS to fail.

The index is decremented before being used, resulting in an
incorrect value when accessing the channel survey data.

Fix the index handling to ensure the correct survey entry is
used and avoid ACS failures.

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3

Fixes: 4f242b1 ("wifi: ath12k: support get_survey mac op for single wiphy") # [1]
Signed-off-by: Yingying Tang <yingying.tang@oss.qualcomm.com>

HAL_TLV_HDR_LEN was using the wrong bitmask; fix it to cover
bits [21:10]. Also drop HAL_SRNG_TLV_HDR_{TAG,LEN} and use the
generic TLV header bit definitions for TLV32/TLV64 encode/decode
to avoid redundant macros.

Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00068-QCACOLSWPL_V1_TO_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3

Fixes: d889913 ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20260509025819.1641630-2-miaoqing.pan@oss.qualcomm.com/

Change TLV decode helpers to return the TLV value pointer and optionally
decode tag/len/usrid via out parameters. This allows reusing the helpers
for DP monitor RX status header TLV parsing and avoids duplicated header
decoding in callers.

No functional change intended.

Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00068-QCACOLSWPL_V1_TO_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3

Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20260509025819.1641630-3-miaoqing.pan@oss.qualcomm.com/

… alignment

Wi-Fi 7 monitor RX status TLV parsing needs to decode TLV headers and
advance the pointer with the correct header alignment. Different targets
use different TLV header layouts (32-bit vs 64-bit), but the HAL ops for
dp_mon RX status header decode and header alignment were not populated
for all wifi7 targets.

Add dp_mon RX status TLV header decode callbacks and TLV header alignment
helpers to the wifi7 HAL ops for QCC2072, QCN9274 and WCN7850. Export
helpers to query the required TLV header alignment for 32-bit and 64-bit
TLV headers so the caller can align the TLV walk correctly across targets.

Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00068-QCACOLSWPL_V1_TO_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3

Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20260509025819.1641630-4-miaoqing.pan@oss.qualcomm.com/

# Conflicts:
#	drivers/firmware/qcom/Kconfig
#	drivers/firmware/qcom/Makefile

# Conflicts:
#	drivers/dma/qcom/bam_dma.c
#	drivers/misc/fastrpc.c
#	sound/soc/qcom/qdsp6/q6prm.h
#	sound/soc/qcom/sc8280xp.c

# Conflicts:
#	Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml

…emory and SMMU mappings"

This change have introduced an issue on multimedia builds where AudioRecord
is broken on monaco-evk board.

[  153.325884] q6apm-lpass-dais 3000000.remoteproc:glink-edge:gpr:service@1:bedais: Failed to start APM port 19
[  153.335982] q6apm-lpass-dais 3000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC error (-110): at soc_dai_trigger() on SEC_MI2S_TX
[  153.348489]  MultiMedia2 Capture: ASoC error (-110): at dpcm_be_dai_trigger() on MultiMedia2 Capture
[  153.357875]  MultiMedia2 Capture: ASoC error (-110): trigger FE cmd: 1 failed

Revert the change for now, to fix the issue.

This reverts commit cd0f5c6.

Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>

This is causing bootup crash on hamoa-iot-evk as the dependency
firmware is still not present.

[    8.804602][  T243] pstate: 41400005 (nZcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[    8.804603][  T243] pc : spi_geni_init+0x44/0x858 [spi_geni_qcom]
[    8.804609][  T243] lr : spi_geni_init+0x38/0x858 [spi_geni_qcom]
[    8.804611][  T243] sp : ffff8000821eb7f0
[    8.804612][  T243] x29: ffff8000821eb7f0 x28: 0000000000000000 x27: 000000000000000c
[    8.804614][  T243] x26: ffffd1d854b495f8 x25: ffff0008129508e0 x24: ffffd1d854b49638
[    8.804616][  T243] x23: ffff800082d54068 x22: ffff0008124a1000 x21: ffff000802ed2010
[    8.804618][  T243] x20: a89ad1d854b41a5c x19: ffff0008124a16c0 x18: ffffd1d874482008
[    8.804620][  T243] x17: ffffd1d874481ff0 x16: ffffd1d872769b48 x15: 0000000000802c80
[    8.804622][  T243] x14: ffff8000821eb130 x13: 0000000160000008 x12: 0000000000000010
[    8.804624][  T243] x11: 0000000000000000 x10: ffff00080d8ee868 x9 : ffffd1d872b9c9c4
[    8.804626][  T243] x8 : ffff8000821eb698 x7 : 0000000000000000 x6 : 0000000000000001
[    8.804628][  T243] x5 : ffffd1d87402b000 x4 : ffffd1d87402b460 x3 : 0000000000000000
[    8.804630][  T243] x2 : ffff00080fc94d40 x1 : ffff00080fc94d40 x0 : 0000000000000000
[    8.804632][  T243] Call trace:
[    8.804633][  T243]  spi_geni_init+0x44/0x858 [spi_geni_qcom] (P)
[    8.804636][  T243]  spi_geni_probe+0x30c/0x3f0 [spi_geni_qcom]
[    8.804638][  T243]  platform_probe+0x64/0xa8
[    8.804642][  T243]  really_probe+0xc8/0x3f0
[    8.804645][  T243]  __driver_probe_device+0x1b4/0x1f0
[    8.804647][  T243]  driver_probe_device+0x44/0x128

Revert the commit for now, to resolve bootup issue.

This reverts commit 181bef7.

Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>

…emory and SMMU mappings"

This change have introduced an issue on multimedia builds where AudioRecord
is broken on lemans-evk board.

[  840.168044] q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: Failed to start APM port 21
[  840.178229] q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC error (-110): at soc_dai_trigger() on TERT_MI2S_TX
[  840.190901]  MultiMedia2 Capture: ASoC error (-110): at dpcm_be_dai_trigger() on MultiMedia2 Capture
[  840.200277]  MultiMedia2 Capture: ASoC error (-110): trigger FE cmd: 1 failed

Revert the change for now, to fix the issue.

This reverts commit f75b90a.

Adding merge log file and topic_SHA1 file

Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>

Qcom platforms has the legacy of using non-standard SCM calls
splintered over the various kernel drivers. These SCM calls aren't
compliant with the standard SMC calling conventions which is a
prerequisite to enable migration to the FF-A specifications from Arm.

OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't
support these non-standard SCM calls. And even for newer architectures
using S-EL2 with Hafnium support, QTEE won't be able to support SCM
calls either with FF-A requirements coming in. And with both OP-TEE
and QTEE drivers well integrated in the TEE subsystem, it makes further
sense to reuse the TEE bus client drivers infrastructure.

The added benefit of TEE bus infrastructure is that there is support
for discoverable/enumerable services. With that client drivers don't
have to manually invoke a special SCM call to know the service status.

So enable the generic Peripheral Authentication Service (PAS) provided
by the firmware. It acts as the common layer with different TZ
backends plugged in whether it's an SCM implementation or a proper
TEE bus based PAS service implementation.

Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/

With the availability of generic PAS service, let's add SCM calls as
a backend to keep supporting legacy QTEE interfaces. The exported
qcom_scm* wrappers will get dropped once all the client drivers get
migrated as part of future patches.

Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/

Add support for Peripheral Authentication Service (PAS) driver based
on TEE bus with OP-TEE providing the backend PAS service implementation.

The TEE PAS service ABI is designed to be extensible with additional API
as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future
extensions of the PAS service needed while still maintaining backwards
compatibility.

Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/

Switch qcom_q6v5_pas client driver over to generic PAS TZ APIs. Generic PAS
TZ service allows to support multiple TZ implementation backends like QTEE
based SCM PAS service, OP-TEE based PAS service and any further future TZ
backend service.

Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/

Switch qcom_q6v5_mss client driver over to generic PAS TZ APIs. Generic PAS
TZ service allows to support multiple TZ implementation backends like QTEE
based SCM PAS service, OP-TEE based PAS service and any further future TZ
backend service.

Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/

Switch mdtloader client driver over to generic PAS TZ APIs. Generic PAS
TZ service allows to support multiple TZ implementation backends like QTEE
based SCM PAS service, OP-TEE based PAS service and any further future TZ
backend service.

Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/

Switch qcom_wcnss client driver over to generic PAS TZ APIs. Generic PAS
TZ service allows to support multiple TZ implementation backends like QTEE
based SCM PAS service, OP-TEE based PAS service and any further future TZ
backend service.

Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/

Select PAS generic service driver to enable support for multiple PAS
backends like OP-TEE in addition to SCM.

Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/

Switch drm/msm client drivers over to generic PAS TZ APIs. Generic PAS
TZ service allows to support multiple TZ implementation backends like QTEE
based SCM PAS service, OP-TEE based PAS service and any further future TZ
backend service.

Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/

Switch qcom media client drivers over to generic PAS TZ APIs. Generic PAS
TZ service allows to support multiple TZ implementation backends like QTEE
based SCM PAS service, OP-TEE based PAS service and any further future TZ
backend service.

Along with that pass proper PAS ID to set_remote_state API. As per testing
the SCM backend just ignores it while OP-TEE makes use of it to for proper
book keeping purpose.

Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/

Switch ipa client driver over to generic PAS TZ APIs. Generic PAS TZ
service allows to support multiple TZ implementation backends like QTEE
based SCM PAS service, OP-TEE based PAS service and any further future TZ
backend service.

Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/

Switch ath12k client driver over to generic PAS TZ APIs. Generic PAS TZ
service allows to support multiple TZ implementation backends like QTEE
based SCM PAS service, OP-TEE based PAS service and any further future TZ
backend service.

Acked-by: Jeff Johnson <jjohnson@kernel.org>
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/

Now since all the Qcom SCM client drivers have been migrated over to
generic PAS TZ service, let's drop the exported SCM PAS wrappers.

Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/

Add Sumit Garg as the maintainer for the Qualcomm generic Peripheral
Authentication Service (PAS) as well as the PAS TEE backend driver.

Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/

qcom_scm_mem_protect_video_var() is not serviced when PAS is backed by
OP-TEE (the TEE owns secure memory protection), so its failure there is
expected. Add qcom_pas_is_tee_backed() to report when the active PAS
backend is the OP-TEE one, and in iris only treat the SCM failure as fatal
when OP-TEE is not on the bus.

Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez.ortiz@gmail.com>

This reverts commit 6a36c4b.

…lator error spam

pm8150_l2 regulator has regulator-max-microvolt set to 3300000 uV, but
the underlying pm660_pldo660 hardware uses 8000 uV steps starting from
1504000 uV. Since 3300000 uV is not a valid hardware step, the regulator
framework's machine_constraints_voltage() silently rounds it down to the
nearest valid step: 3296000 uV (step 224 = 1504000 + 224 * 8000).

During MMC/SD card detection cycles, mmc_set_initial_signal_voltage()
attempts to set 3.3V signaling by calling mmc_regulator_set_vqmmc(),
which uses regulator_set_voltage_triplet() to first try the target
voltage (3500000 uV) before falling back to the minimum. Since
3500000 > 3296000, regulator_check_voltage() logs an error:

  l2: unsupportable voltage range: 3500000-3296000uV

The fallback to 3200000 uV succeeds, but if card detection is
continuously retrying (e.g., no card present, card detect failure, or
initialization errors), this error is logged every ~200ms, spamming the
kernel log.

Fix this by raising regulator-max-microvolt to 3504000 uV, which is a
valid hardware step (step 250 = 1504000 + 250 * 8000). This allows the
3.5V target voltage request to succeed on the first attempt, eliminating
the error log. The value is within the SD specification (vqmmc up to
3.6V for 3.3V signaling) and within the hardware range (max 3544000 uV).

Fixes: fa7b0cd ("arm64: dts: qcom: Add regulator for Retail and Industrial SOM variants")
Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>